WEBVTT
Kind: captions
Language: zh-Hans

00:00:00.000 --> 00:00:02.317
虽然你的手机游戏很棒

00:00:02.318 --> 00:00:05.900
但是用户却抱怨加载时间太长

00:00:05.900 --> 00:00:08.720
经过一些性能分析后  找到了问题所在

00:00:08.720 --> 00:00:11.840
你花了很多时间来加载游戏数据

00:00:11.840 --> 00:00:14.032
我是Colt  McAnlis

00:00:14.033 --> 00:00:16.337
我们的新型flatbuffers库

00:00:16.338 --> 00:00:17.828
可以让用户感到加载更快

00:00:17.829 --> 00:00:19.320
让你觉得设计更简单

00:00:19.320 --> 00:00:23.040
如你所知  内容加载真是个超级慢的过程啊.

00:00:23.040 --> 00:00:26.293
所有内容工具菜单的游戏数据存在某个格式里的

00:00:26.294 --> 00:00:29.375
例如  物理  动画  电子表格数据

00:00:29.376 --> 00:00:32.800
这些装在你游戏里的数据  转换给用户

00:00:32.800 --> 00:00:34.584
它还能计算临时数据

00:00:34.585 --> 00:00:39.740
比如通过网络连接发送你的游戏数据然后重新加载

00:00:39.740 --> 00:00:42.168
因为这个过程对游戏开发至关重要

00:00:42.169 --> 00:00:44.920
那我们如何去优化她的性能呢

00:00:44.920 --> 00:00:46.660
要做到这一点  我们回到最基本的东西上来

00:00:47.140 --> 00:00:52.273
序列化的过程就是将内存中的数据结构转换为数据格式

00:00:52.274 --> 00:00:56.734
第一  在某种情况下  可以转换为内存

00:00:56.735 --> 00:01:01.900
第二  说简单点就是可以不用占用太多空间

00:01:01.900 --> 00:01:05.218
现在  一些常用的序列化格式就是XML和JSON

00:01:05.219 --> 00:01:08.260
主要是因为它对于普通人而言  它易于阅读

00:01:08.260 --> 00:01:10.680
也就是说  你可以在文本编辑器中打开这些文件

00:01:10.681 --> 00:01:13.760
随性的修改文件  并且还能够很好的知道自己所做的

00:01:13.760 --> 00:01:15.792
这个已经普及到了语言的支持

00:01:15.793 --> 00:01:19.700
例如C# Java 和JavaScript

00:01:19.700 --> 00:01:22.900
但是事实上  这些格式还是有些严重的不足的

00:01:22.900 --> 00:01:28.648
首先  他们内容过大  过于冗长的句法使得这些格式

00:01:28.649 --> 00:01:30.792
具有可读性和易用性

00:01:30.793 --> 00:01:34.840
使得文件比他实际需要还要大得多

00:01:34.840 --> 00:01:37.940
其次  这些格式的太过于固定的性质

00:01:37.941 --> 00:01:41.040
使得反序列过程遇上了更大的阻力

00:01:41.040 --> 00:01:44.874
解析系统先读入字符串数据  然后运行分析

00:01:44.875 --> 00:01:49.860
以确定哪种数据类型在转换之前可以安放于内存中

00:01:49.860 --> 00:01:53.335
更糟的是  当你的格式支持更先进的类型

00:01:53.336 --> 00:01:56.080
如界面 时间戳  对象

00:01:56.080 --> 00:01:58.286
一旦复杂度达到一定值的时候

00:01:58.287 --> 00:02:01.680
那么结果就是关于速度的反序列问题

00:02:01.680 --> 00:02:03.850
为了处理这些问题  我们已经开发了一个

00:02:03.851 --> 00:02:06.820
叫做flatbuffers的新游戏的开放源码工具

00:02:06.820 --> 00:02:10.096
这个库回到基本序列化  也就是说

00:02:10.097 --> 00:02:12.932
在快速的编码和解码的同时

00:02:12.933 --> 00:02:16.240
也可能产生最小的编码文件

00:02:16.240 --> 00:02:19.285
现在  说得高深点  就是flatbuffers

00:02:19.286 --> 00:02:21.113
依靠创建一个描述将被序列化的

00:02:21.114 --> 00:02:22.940
数据类型文件来运行称之为模式

00:02:22.940 --> 00:02:26.748
然后被移交给可以生成代码文件的句法编译器

00:02:26.749 --> 00:02:32.080
你可以在应用程序中包含编码或者解码你已定义的格式

00:02:32.080 --> 00:02:34.218
因为你游戏结构是复杂的

00:02:34.219 --> 00:02:36.936
你编入的编译程序模式的结构

00:02:36.937 --> 00:02:40.282
允许你描述数据结构的原始关系类型

00:02:40.283 --> 00:02:45.300
例如  可重用对象类型  枚举类型和基本类型

00:02:45.300 --> 00:02:49.500
这个结构使得flatbuffers更加安全

00:02:49.501 --> 00:02:52.786
不需要任何类型转换  内存分配

00:02:52.787 --> 00:02:55.388
就算在加载时也不用解压

00:02:55.389 --> 00:02:58.700
这绝对是一个速度的大提升

00:02:58.700 --> 00:03:02.300
只要你创建好了所有可序列化数据的文件模式

00:03:02.301 --> 00:03:07.520
这些模式就可以被你应用到C编译器  生成游戏源代码

00:03:07.520 --> 00:03:09.256
通过准确的命令行触发器

00:03:09.257 --> 00:03:12.028
你可以生成C++ Java甚至是

00:03:12.029 --> 00:03:16.360
你可以转回到repo（指安装位置）和编译源代码文件

00:03:16.360 --> 00:03:18.413
现在  不管你用的是什么编程语言

00:03:18.414 --> 00:03:21.880
使用flatbuffers加载数据都是超级简单

00:03:21.880 --> 00:03:25.027
是一款没有推特注册教程语法编辑和内置FTP功能

00:03:25.028 --> 00:03:28.860
但它有一个其他编辑器不具备的特性推特翻墙软件下载

00:03:21.880 --> 00:03:22.655
序列化流字节

00:03:22.656 --> 00:03:25.370
传递给单行CodeToGo(掌上代码)

00:03:25.371 --> 00:03:28.860
转换成你需要的对象  最后你就可以准备使用它啦

00:03:29.920 --> 00:03:33.180
现在  一切都已经完备啦  但是它究竟有多快呢

00:03:33.180 --> 00:03:35.587
我们来看看flatbuffers与其他一些格式

00:03:35.588 --> 00:03:36.634
相比较而言是怎么样的

00:03:36.635 --> 00:03:38.100
比如缓冲器和JSON

00:03:38.100 --> 00:03:41.690
我们可看到  关于解码和编码时间这个重要因素

00:03:41.691 --> 00:03:45.280
flatbuffers打败了其他方式

00:03:45.280 --> 00:03:47.487
事实上  当flatbuffers并排

00:03:47.488 --> 00:03:50.160
你不能看到flatbuffers时间图

00:03:50.160 --> 00:03:54.560
恩 现在重要的是测试数据的编码大小

00:03:54.560 --> 00:03:57.612
在短暂的的编码和解码时间里  可以看到

00:03:57.613 --> 00:04:01.341
涉及到数据的原始大小以及zlib压缩版本时

00:04:01.342 --> 00:04:04.360
flatbuffers最小的

00:04:04.360 --> 00:04:07.540
对了  还有个事儿如果你改变游戏的数据格式时

00:04:07.541 --> 00:04:11.356
它会伴随着旧格式  兼容性引起大混乱

00:04:11.357 --> 00:04:13.900
你知道这将会是怎么样的情况吗

00:04:13.900 --> 00:04:16.496
Flatbuffers却不存在这样的问题发生

00:04:16.497 --> 00:04:18.649
因为在不影响原数据和原程序的前提下

00:04:18.650 --> 00:04:21.723
Flatbuffers提供演变模式的功能依我看

00:04:21.724 --> 00:04:23.460
听起来这个是超炫的事儿

00:04:23.460 --> 00:04:26.477
当然  在这个项目中还有更好的特性留待

00:04:26.478 --> 00:04:28.000
研究和探索想要了解

00:04:28.001 --> 00:04:31.046
更多关于flatbuffers的文库

00:04:31.047 --> 00:04:33.585
或者想知道在这个下是怎样运行的

00:04:33.586 --> 00:04:36.800
看看flatbuffers文档页码

00:04:36.800 --> 00:04:39.050
序列化数据不应该是个痛苦的事儿

00:04:39.051 --> 00:04:41.600
现在就去创建个好玩儿的游戏

00:04:42.820 --> 00:04:51.100
好玩儿的游戏----我们写押韵了吗